TS 101 319 V1. 6.4 (1998-12) 



Technical Specification 



Telecommunications and Internet Protocol 

Harmonization Over Networks (TIPHON); 

Signalling for basic calls from an H.323 terminal to a terminal 

in a Switched-Circuit Network (SCN) 




TS101 319 V1. 6.4 (1998-12) 



Reference 



DTS/TIPHON-03002 (c7o00k2r.PDF) 

Keywords 
internet, IP, signalling, telephony, voice. 



ETSI 

Postal address 



F-06921 Sophia Antipolis Cedex - FRANCE 

Office address 

650 Route des Lucioles - Sophia Antipolis 

Valbonne - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N" 7803/88 



Internet 



secretariat@etsi.fr 

Individual copies of this ETSI deliverable 

can be downloaded from 

http://www.etsi.org 



Copyright Notification 



No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 1998. 
All riglits reserved. 



ETSI 



TS101 319 V1. 6.4 (1998-12) 



Contents 



Intellectual Property Rights 5 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 8 

4 Entities participating in the setup of a basic call 8 



5 Registration, call setup and call release 8 

5.1 Overview 8 

5.2 Security principles 9 

5.3 Registration 9 

5.3.1 Registration basics 9 

5.3.2 Authenticated registration 9 

5.3.3 Anonymous registration 9 

5.3.4 Registration keep alive 9 

5.4 Call setup 10 

5.4.1 Prerequisites 10 

5.4.2 The en-bloc procedure 10 

5.4.3 Overlap sending 10 

5.4.4 Establishment of media channels 10 

5.4.4.1 Fast Connect procedure 10 

5.4.4.2 Encapsulation of H. 245 messages within H. 225.0 messages 10 

5.4.5 Dual Tone Multi Frequency (DTMF) signalling 10 

5.4.6 Basic call setup 1 

5.4.7 Carrier selection 1 

5.5 Active phase 1 

5.5.1 General aspects 1 

5.5.2 Exceptional cases during the active phase 1 

5.6 Call release 12 

5.7 Calling Line Identification (CLl) 12 

Annex A (normative): Required support of ITU-T Recommendation H.225.0 call control 

protocol 13 

A.l Message definitions 13 

A.1.1 Alerting 13 

A. 1.2 Information 14 

A. 1.3 Release Complete 14 

A. 1.4 Setup 14 

A. 1.5 Setup Acknowledge 14 

Annex B (normative): Interoperable security profiles 15 

B.l Security Profile B.l 15 

Annex C (informative): Message flows for call setup 16 

C.l Gatekeeper routed calls 16 

C.1.1 H.323 Terminal and Gateway registered to same Gatekeeper, fast connect procedure, overlap procedure 16 



ETSI 



4 TS 1 01 31 9 VI .6.4 (1 998-1 2) 

Annex D (informative): Basic call scenario definitions 17 

D.l Successful calls 17 

D.2 Unsuccessful calls 17 

D.3 Call failures 17 

D.4 Calling line identification (CLI) 17 

D.4.1 Presentation number 18 

D.4.2 Network number 19 

D.5 In-band information 19 

D.5.1 Call to operator/Non-chargeable calls 20 

D.5.2 IN Services 20 

Bibliography 21 

History 22 



ETSI 



TS101 319 V1. 6.4 (1998-12) 



Intellectual Property Rights 
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in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 
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1 Scope 



The present document describes interactions between ITU-T Recommendation H.323 [10] Terminals, Gatekeepers, 
Gateways, and Switched-Circuit Networks (SCN) for support of TIPHON scenario 1, see TR 101 306 [18]. 

The present document specifies a profile to be applied to the ITU-T Recommendation H.323 [10] for the purposes of 
TIPHON compliant systems. 

Call trace protocols, e.g. for use in tracing malicious calls, are outside the scope of the present document. 

The present document is applicable to Basic Call for voice only telephone calls from an H.323 Terminal on a network 
using Internet Protocol transport to Terminals on SCNs, e.g. Public Switched Telephone Network (PSTN), Integrated 
Services Digital Network (ISDN) or GSM Public Land Mobile Network (PLMN). 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] EN 300 092-1: "Integrated Services Digital Network (ISDN); Calling Line Identification 
Presentation (CLIP) supplementary service; Digital Subscriber Signalling System No. one (DSSl) 
protocol". 

[2] Void. 

[3] EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalhng System 

No. one (DSSl) protocol; Signalling network layer for circuit-mode basic call control; Part 1: 
Protocol specification [ITU-T Recommendation Q.931 (1993), modified]". 

[4] ETS 300 659-1 (1997): "PubUc Switched Telephone Network (PSTN); Subscriber line protocol 

over the local loop for display (and related) services; Part 1: On hook data transmission". 

[5] ISO/IEC 1 1572 (1996): "Information Technology - Telecommunications and information exchange 

between systems - Private Integrated Services Network - Circuit mode bearer services - 
Inter-exchange signalling procedures and protocol". 

[6] ITU-T Recommendation H. 225.0 (1998): "Call signalling protocols and media stream 

packetization for packet based multimedia communication systems". 

[7] ITU-T Recommendation H.235 (1998): "Security and encryption for H Series (H.323 and other 

H.245 based) multimedia terminals". 

[8] ITU-T Recommendation H.245 (1998): "Control protocol for multimedia communication". 

[9] Void. 

[10] ITU-T Recommendation H.323 (1998): "Packet-based multimedia communications systems". 

[II] ITU-T Recommendation Q.731.3 (1993): "Calling Line Identification Presentation (CLIP)". 

[12] ITU-T Recommendation Q.761 (1997): "Signalhng System No. 7 - ISDN User Part functional 

description". 
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[13] ITU-T Recommendation Q.762 (1993): "Specifications of Signalling System No. 7; General 

Function of Messages and Signals of the ISDN User Part of Signalling System No. 7". 

[14] ITU-T Recommendation Q.763 (1993): "Specifications of Signalling System No. 7; Formats and 

Codes of the ISDN User Part of Signalling System No. 7". 

[15] ITU-T Recommendation Q.764 (1993):"Specifications of Signalling System No. 7; Signalling 

System No. 7 - ISDN User Part Signalling Procedures". 

[16] ITU-T Recommendation Q.931 (1993): "ISDN user-network interface layer 3 specification for 

basic call control". 

[17] ITU-T Recommendation Q.932 (1993): "Digital Subscriber Signalling System No. 1 (DSSl) - 

Generic procedures for the control of ISDN supplementary services". 

[18] TR 101 306 (1998): "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Requirements for service interoperability; Scenario 1". 

[19] TS 101 312 (1998): "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Network architecture and reference configurations; Scenario 1". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

access token: An octet string which may be present in Registration, Admission, and Status (RAS) messages and the 
Setup message. It is used to specify the identity, authorization, or other security characteristics of a network element or a 
user. 

call: See "telephone call". 

endpoint: An H.323 Terminal or Gateway. An endpoint can call and be called. It generates and/or terminates 
information streams. 

gatekeeper: The Gatekeeper is an H.323 entity on the network that provides address translation and controls access to 
the network for H.323 Terminals, Gateways and Multipoint Control Units (MCU). The Gatekeeper may also provide 
other services to the H.323 Terminals, Gateways and MCUs such as bandwidth management and locating Gateways. 

gateway: An H.323 Gateway is an endpoint on the network which provides for real-time, two-way communications 
between H.323 Terminals on the packet based network and other Terminals on a switched circuit network. 

H.323 Terminal: An entity which provides audio and optionally video and data communications capability in 
point-to-point or multipoint conferences in packet-based networks. 

telephone call: Two-way speech communication between two users by means of Terminals via network infrastructure. 
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3.2 



Abbreviations 



In addition to the abbreviations given in TR 101 306 [18] and TS 101 312 [19], the following abbreviations apply: 



ACF 

ARJ 

ARQ 

CLI 

CLIP 

DSSl 

DTMF 

GSM 

IN 

IP 

ISDN 

ISUP 

MCU 

NNI 

PLMN 

PSTN 

RAS 

RCF 

RRQ 

SCN 

UNI 



AdmissionConfirm (RAS message) 

AdmissionReject (RAS message) 

AdmissionRequest (RAS message) 

Calling Line Identification 

Calling Line Identification Presentation 

Digital Subscriber Signalling System No. one 

Dual Tone Multi Frequency 

Global System for Mobile communication 

Intelligent Network 

Internet Protocol 

Integrated Services Digital Network 

ISDN User Part (of CCITT number 7 signalling) 

Multipoint Control Units 

Network-to-Network Interface 

Public Land Mobile Network 

Public Switched Telephone Network 

Registration, Admission, and Status 

RegistrationConfirm (RAS message) 

RegistrationRequest (RAS message) 

Switched-Circuit Network 

User-to-Network Interface 



4 Entities participating in the setup of a basic call 

The TIPHON system is a multi-component environment system. It consists of H.323 Terminals, Gateways, and 
Gatekeepers. For more details about these entities and the scenarios in which they are acting, refer to TS 101 312 [19]. 



Registration, call setup and call release 



5.1 



Overview 



The procedures of ITU-T Recommendations H.323 [10], H.225.0 [6] and H.245 [8] shall apply with the limitations or 
extensions described in the present document. The procedures of ITU-T Recommendations H.235 [7] shall apply 
unchanged. 

In accordance with ITU-T Recommendation H.323 [10], the protocols defined in ITU-T Recommendations H.225.0 [6], 
H.245 [8] shall be used as the protocols for call control signalling and logical channel controlling within the packet 
based data network. The use of ITU-T Recommendations H.225.0 [6] and H.245 [8] is specified in more detail in the 
following subclauses. 

NOTE: ITU-T Recommendation H.225.0 defines two protocols: Registration, Admission, and Status (RAS) and a 
ITU-T Recommendations Q.931-like protocol. 

Annex A describes changes to the ITU-T Recommendations Q.931 [16] messages and the contents of messages carried 
by the User-to-user information element in ITU-T Recommendation H.225.0 [6]. 

The RAS protocol shall apply unchanged. 

The ASN.l definitions given in annex H of ITU-T Recommendation H.225.0 [6] shall be used. 
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The precise translation of ITU-T Recommendation H.323 [10] messages to the SCN shall depend on the nature of the 
SCN (an ISDN, a PSTN, etc.) and the level of connectivity to be supported. This translation shall provide support, as 
necessary, of: 

the semantics of the protocol specified in ITU-T Recommendations Q.761 [12], Q.762 [13], Q.763 [14], 
Q.764 [15] and Q.931 [16] with variations in implementation appropriate to the region in which the SCN 
operates; or 

- the protocol specified in ISO/IEC 1 1572 [5]. 

5.2 Security principles 

TIPHON compliant systems shall support security services. They are not required to always be activated. 

5.3 Registration 

5.3.1 Registration basics 

Both H.323 Terminals and Gateways shall register with Gatekeepers. Registration shall be in accordance with 
ITU-T Recommendation H.323 [10] procedures. 

NOTE: Gateway performance may be enhanced if the Gatekeeper issues the PreGrantedARQ indication in the 
RegistrationConfirm (RCF) message on successful registration of the Gateway. 

Two types of registration shall be supported: 

authenticated registration with the Gatekeeper; 

anonymous registration with the Gatekeeper. 

5.3.2 Authenticated registration 

Authenticated registrations shall be in accordance with the security profiles in annex B. 

5.3.3 Anonymous registration 

In this case the RRQ message shall not contain an access token. 

NOTE: The intention here is to allow certain types of call, e.g. Freephone. The types of call are service provider 
dependent. 

5.3.4 Registration keep alive 

Endpoints shall support the keep alive procedure as specified in subclauses 7.2.2 and 8.4.2 of 
ITU-T Recommendation H.323 [10]. If the registration ceases to be valid (e.g. the connection between the H.323 
Terminal and the Gatekeepter goes down for some reason), the Gatekeeper shall remove the registration and release all 
ongoing calls. A new registration may be established using the procedures of ITU-T Recommendation H.323 [10]. 
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5.4 Call setup 

5.4.1 Prerequisites 

Calls between users in the IP network and users in the SCN shall be setup only after successful registration according to 
subclause 5.3. 

The sequences in annex C are built on the principles described in the following subclauses. 

5.4.2 The en-bloc procedure 

If a CALL PROC message is returned to the H.323 Terminal, the "Sending complete" information element shall be 
inserted, if not already there, in the SETUP message towards the next network element (e.g. next Gatekeeper or a 

Gateway). 

5.4.3 Overlap sending 

On receipt of such a SETUP message, the Gatekeeper starts timer T302 (the value of timer T302 is specified in 
ITU-T Recommendation Q.931 [16]) and sends a SETUP ACKNOWLEDGE message to the H.323 Terminal. 

The Gatekeeper shall restart timer T302 on the receipt of every INFORMATION message not containing a sending 
complete indication and containing the called party information element with at least one valid character. 

5.4.4 Establishment of media channels 

5.4.4.1 Fast Connect procedure 

TIPHON-compliant systems shall use the Fast Connect procedure of ITU-T Recommendations H.323 [10], 
subclause 8.1.7. 

NOTE 1: This includes the capability to negotiate media channels using ITU-T Recommendation H.245 or to fall 
back to ITU-T Recommendation H.245 signalling at any time of the call. 

NOTE 2: This enables in-band information to be passed prior to call establishment. 

5.4.4.2 Encapsulation of H.245 messages within H. 225.0 messages 

TIPHON-compliant systems shall support encapsulation of ITU-T Recommendation H.245 [8] messages within 
ITU-T Recommendation H. 225.0 [6] messages according to ITU-T Recommendations H.323 [10], subclause 8.2.1. 

NOTE: Encapsulation of H.245 messages within H. 225.0 is preferred to a separate H.245 channel because of its 
greater efficiency. 

5.4.5 Dual Tone Multi Frequency (DTMF) signalling 

Transfer of the DTMF tones shall be by means of the ITU-T Recommendation H.245 [8] message userlnputlndication. 
NOTE: The userlnputlndication could be tunnelled via the FACILITY message if necessary. 
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5.4.6 Basic call setup 



Calls shall be setup using the procedures defined in ITU-T Recommendations H.323 [10] with the following 
changes/clarifications : 

within the context of this specification, call setup uses only one user channel towards the SCN. Calls requiring a 
number of user channels will not be supported; 

the Gatekeeper and the Gateway shall support both the en-bloc and the overlap sending procedure. 

NOTE 1: Annex C, "Message flows for call setup", gives one possible mapping of messages to and from the SCN 
for overlap sending with fast connect. 

If an element or a message not allowed to be used within the context of this specification is received, the receiver shall 
pass on, but otherwise ignore, the message or the element i.e. the receiver shall act as if the message or the element was 
not received. 

If a element is received with a value, not allowed within the context of this specification, the receiver shall, if the 
element is optional, pass on, but otherwise ignore, the element (act as if the element is not received) or if the element is 
mandatory act as if the default value was received. 

NOTE 2: The security policy of an operator's network or the security policy implemented in a network element may 
override the error handling as described above. 

5.4.7 Carrier selection 

Carrier selection shall be performed by transmitting the necessary information to the Gatekeeper and Gateway within the 
called party number field. This procedure shall not preclude overlap sending. 

5.5 Active phase 

5.5.1 General aspects 

The active phase of the call shall commence when the called party answers and the Gateway issues the Connect 
message as a result. 

Upon detection of failure of the call in the IP network, accounting and charging functions shall be informed. 

NOTE 1: In order to detect call failures in the IP network, which affect accounting and charging functions. 
Gatekeepers should specify an irrFrequency value inside the AdmissionConfirm (ACF) message. 

Transfer of the DTMF tones shall be by means of the ITU-T Recommendation H.245 [8] message userlnputlndication. 

NOTE 2: The userlnputlndication could be tunnelled via the FACILITY message if necessary. 

5.5.2 Exceptional cases during the active phase 

If the Gatekeeper detects a failure, the Gatekeeper shall initiate clearing of the call as described in subclause 5.6. 

If the Gateway detects a failure, the Gateway shall initiate clearing towards the SCN, and clear the call in the IP network 
as described in subclause 5.6, towards the IP network. 

If the H.323 Terminal detects a failure, the H.323 Terminal shall initiate clearing of the call as described in 
subclause 5.6. 
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5.6 Call release 



Call release may be initiated by the H.323 Terminal, the Gateway, or the Gatekeeper. The reason for initiating call 
release may, e.g. be normal disconnection of a call or a call failure. 

Message collisions shall be handled by H.323 Terminals, Gatekeepers and Gateways. 

NOTE: Message collision occurs when the endpoint and the Gateway initiate clearing at the same time. 

5.7 Calling Line Identification (CLI) 

CLI information may be provided by calling users and may be received by called users. When a user wishes to provide a 
calling number it shall be provided using the signalling elements described in ITU-T Recommendation H. 225.0 [6]. 

Users may provide a number using the optional Calling Party Number information element in the Setup message. 

NOTE: The procedures and protocols for handling these information elements may be defined in regional and 
national regulations and/or codes of practice. Wherever such requirements exist they may supersede the 
requirements expressed here. 

According to ITU-T Recommendation H. 225.0 [6] the number cannot have qualifications defined in accordance with 
octet 3a information (Presentation Indicator and Screening Indicator) as in tables 4 to 11 of 

ITU-T Recommendation Q.931 [16]. Accordingly, in the absence of octet 3a information, the calling party number 
information element shall be treated as if octet 3a contained the following values: 

1) "presentation allowed"; and 

2) "user-provided not screened". 
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Annex A (normative): 

Required support of ITU-T Recommendation H. 225.0 call 

control protocol 

ITU-T Recommendation H.323 [16], uses a call control protocol derived from ITU-T Recommendations Q.931 [16] 
which is specified in the ITU-T Recommendation H. 225.0 [6]. 

This annex defines a profile which is intended to clarify the use of ITU-T Recommendation H. 225.0 [6] in TIPHON- 
compliant systems. Whenever the contents of this annex are in conflict with ITU-T Recommendation H. 225.0 [6] this 
annex shall take precedence. 

The current version of the ITU-T Recommendations Q.931 [16] part of ITU-T Recommendation H. 225.0 [6] includes a 
number of optional messages and information elements. The EN 300 403-1 [3] standard forbids some of the information 
elements which are optional in ITU-T Recommendation H. 225.0 [6], listed below. Gateways that interconnect with 
ETSI DSSl networks shall not send these information elements. 

Table A.l identifies changes to entries in table 4 of ITU-T Recommendation H.225.0 [6]. 

The changes in the table shall apply to TIPHON Phase 1 systems. 

Table A.l : Modification to ITU-T Recommendation H.225.0 [6] and Usage of Q.931 [16] and Q.932 [17] 

Messages 



Call Establishment Messages 


Transmit (M, CM) 


Receive and act on 
(M, CM) 


Call Proceeding 


M 


M 


Progress 


M 


M 


Setup Acknowledge 


M 


CM (see note) 








Miscellaneous Messages 






Information 


CM 


M 


NOTE : Only mandatory if the H.323 Terminal indicates canOverlapSend in the Setup 
message. 
IVI = mandatory, CM = conditionally mandatory. 



A.1 Message definitions 



A. 1.1 Alerting 

Table A. 2 identifies changes to entries in table 5 of ITU-T Recommendation H.225.0 [6]. 

Table A.2: Modifications to ITU-T Recommendation H.225.0 [6] Usage of the Alerting message 



Information element 


H.225.0 Status 


Length in H.225.0 


Signal 


F (see note) 


NA 


NOTE : F = forbidden 

Na = not applicable 
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A.1.2 Information 

Table A. 3 identifies changes to entries in table 9 of ITU-T Recommendation H.225.0 [6]. 
Table A.3: Modifications to ITU-T Recommendation H.225.0 [6] Usage of the Information message 



Information element 


H.225.0 Status 


Length in H.225.0 


Signal 


F 


NA 



A.1 .3 Release Complete 

Table A.4 identifies changes to entries in table 10 of ITU-T Recommendation H.225.0 [6]. 

Table A.4: Modifications to ITU-T Recommendation H.225.0 [6] Usage 
of the Release Complete message 



Information element 


H.225.0 Status 


Length in H.225.0 


Signal 


F 


NA 



A. 1.4 Setup 



Table A. 5 identifies changes to entries in table 11 of ITU-T Recommendation H.225.0 [6]. 

Table A.5: Modifications to ITU-T Recommendation H.225.0 [6] Usage of the Setup message 



Information element 


H.225.0 Status 


Length in H.225.0 


Signal 


F 


NA 



A.1 .5 Setup Acknowledge 



The contents and semantics of a SETUP ACKNOWLEDGE message received from the network are defined in 

tables 3 to 16 of ITU-T Recommendations Q.931 [16] with the single modification that the Signal information element 

is not allowed. 
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Annex B (normative): 
Interoperable security profiles 



Compliant systems shall provide security services according to one or more of the following interoperable security 
profiles. These profiles shall identify their purpose, and they shall specify the method, cryptographic algorithms, and 
cryptographic parameters (e.g. key lengths) for: 

the five security services (authentication, access control, non-repudiation, confidentiality, and integrity); 

four or more protocol components (RAS, H. 225.0, H.245, RTP); 

- the security information flows identified in TS 101 312 [19] (S1-S17). 

As a convenient reference, profiles may include a summary matrix derived from the following form for each security 
information flow. 

Table B.I : Profile summary matrix 



Security Services 


Call Functions 




RAS 


H.225.0 


H.245 


RTP 


Other(s) 


Authentication 












Access Control 












Non-Repudiation 












Confidentiality 












Integrity 













Each element in the matrix shall identify the security mechanism (e.g. Not applicable. None, IPSEC, TLS/SSL, Access 
Token, H.235, or Other) and the cryptographic algorithm(s) and parameters supported. 

In addition, each profile description shall include the detailed information sufficient to ensure interoperability, and lists 
the attacks it counters, the provided security level, and the potential consequences of a breach in its security. 

If a profile includes multiple tables (e.g. for multiple security information flows), then the security mechanisms specified 
for each service shall not contradict each other. 

NOTE: All security profiles are referred to by their clause number in this annex (e.g. "Profile B.l") rather than a 
descriptive term. 



B.1 Security Profile B.1 



Security profile B.l provides no security services whatsoever. All elements in the summary matrix list a security 
mechanism of "None." It is appropriate for networks where security is not provided or not permitted or provided by 
other means (e.g. physical isolation). 

Table B.2: Security Profile B.l 



Security Services 


Call Functions 




RAS 


H.225.0 


H.245 


RTP 


Authentication 


None 


None 


None 


None 


Authorization 


None 


None 


None 


None 


Non-Repudiation 


None 


None 


None 


None 


Privacy 


None 


None 


None 


None 


Integrity 


None 


None 


None 


None 



Additional profiles will be defined in the future. 
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Annex C (informative): 
Message flows for call setup 

C.1 Gatekeeper routed calls 

The signalling procedures, described in the following subclause, are based on the Gatekeeper routed model. 

C.1 .1 H.323 Terminal and Gateway registered to same 

Gatekeeper, fast connect procedure, overlap procedure 



Gateway 



SCN 





ARQ 






Setup 




Setup 






ARJ 




ACF 




Setup 






Setup ack 






Setup ack 




^ 




Information 






Setup ack 










Information 




Information 






Call Proceeding 










Cali Proceeding 




Call Proceeding 






Med 


a channel activated 






- 








Alerting 




Alerting 




Alerting 






Connect 


^ Connect | 




Connect 





















(note 2) 



NOTE 1 : This figure is given only for informative purposes and reflects ITU-T Recommendation Q.931 [1 6] cases 

only. 
NOTE 2: If the SCN has received sufficient digits to complete number analysis, Call Proceeding shall be sent 

instead of Setup Ack in response to Setup and the Information message will be discarded. 
NOTE 3: In this flow diagram the ARQ/ACF procedure between Gateway and Gatekeeper is not performed since 

preGrantedARQ is assumed. 

Figure C.1 : Fast call setup using overlap sending and Gatekeeper routed call model within a Zone 
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Annex D (informative): 
Basic call scenario definitions 

D.1 Successful calls 

A successful call is one in which the SCN receives the called address and routes the call to a network Terminal which 
can accept two way speech communication. The network signalling will normally have sent an Answer signal back from 
the terminating exchange. The generally understood meaning of this is that the calling user is able to speak to a user 
handling calls directed at the called address or to some automatic call answering device. The normal expectation is that 
the caller will be required to pay for such calls. 

In addition to the simple meaning above there are cases, notably associated with mobile telephones, where network 
operators send back an answer signal even though two way speech has not been established. The normal expectation is 
that the caller will be required to pay for such calls. 



D.2 Unsuccessful calls 



Unsuccessful calls do not reach the two way or one way speech condition which follows Answer. The reasons for this 
are for example: 

caller clears prior to ringing; 

caller clears prior to answer; 

called party is engaged on another call; 

called party is not accepting calls; 

called party does not answer; 

network congestion is encountered. 

In all of these cases the user is not offered the service associated with a successful call but there is no fault in the 
network. 



D.3 Call failures 



A call failure occurs when the network fails to complete a call and is therefore neither successful or unsuccessful. A call 
failure also occurs when an established call, whether or not answer has occurred, is broken down as a result of 
equipment failure. The normal expectation is that customers do not pay for calls after the point at which the fault is 
detected. 



D.4 Calling line identification (CLI) 

The following subclauses deal with two kinds of calling line identity. The general purpose is to ensure that a CLI is 
offered to the SCN for use by the terminating network. At present there is no definition of a mechanism for withholding 
CLI information derived by authentication or given as a presentation number. The behaviour of a TIPHON Gateway is 
that the presentation indicator is set to Presentation Allowed in the SETUP and lAM messages. If a Gateway does not 
have any number as a result of authentication or supplied presentation number the network number alone is supplied. 
The presentation indicator for network number is set to Presentation Restricted. In the case where no network number is 
available for whatever reason the value of the indicator is set to Number not available due to inter- working. 

Thus when a user either supplies a presentation number or arranges for the network number to be displayed the relevant 
presentation indicators are set to presentation allowed. 
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D.4.1 Presentation number 



If a user wants the called party to receive a presentation number it can be achieved by putting a suitable E.164 number in 
the Calling party number parameter of the SETUP message If the calling user has a special arrangement with the service 
provider, as described in EN 300 092-1 [1]. The type of number field may be a "subscriber number", "national number" 
or "international number" as specified in EN 300 092-1 [1] with code point values defined in subclause 4.5.10 of 
EN 300 403-1 [3]. 

The Gatekeeper may use the number supplied by the H.323 Terminal as well as the identification of the user determined 
by the authentication process. If the number appears to be a valid one, the user is authorized to provide presentation 
numbers and the interface from the Gateway is an NNI, the number can be forwarded to the public network as "User 
provided, verified, and passed". If the interface is a UNI, the number will be passed to the network in exactly the same 
form as it was supplied in the ITU-T Recommendation H. 225.0 [6] SETUP message. This number will be converted into 
a presentation number if the ISDN exchange allows the facility. 

There is another way of generating a CLI to send to the called party. The user need not provide a number in the calling 
party field instead the Gatekeeper accesses a presentation number database indexed by the identification derived from 
the authentication operation. If the connection forwards into the narrow-band network is ISUP the number may be 
passed as "user provided, verified, and passed". This behaviour is specified in the Stage 3 Description for CLIP in ISUP, 
ITU-T Recommendation Q. 73 1.3 [11]. If the interface to the narrow-band network is a UNI the calling party field is 
passed on in the same form as it was supplied by the user. The range of CLI values which can be passed over such an 
interface will make verification by the public network impossible. The UNI should therefore be registered with the 
service provider as one which uses the special arrangement described in subclause 6.2 of the CLIR protocol 
specification, EN 300 092-1 [1]. The consequence of this is that all calling numbers passed over this interface will be 
delivered as "User provided, not verified". 

Whichever way it is generated the calling number is passed over the network to the terminating exchange where it is 
passed to the called party. If the called party is connected using ISDN the calling number information is passed 
unchanged in accordance with EN 300 403-1 [3]. For PSTN lines with the CLI display service the number is sent in 
accordance with ETS 300 659-1 [4] for on hook signalling. In ISDN the calling party number information element is 
passed on unchanged to the called party only if he subscribes to the CLIP service. In the case of an analogue with caller 
display the number is always delivered but the qualification, see below, of the calling number is not necessarily sent. 
This is because the qualification parameter is not in a normative part of the specification. Nevertheless the qualification 
type values are identical to the ISDN case, i.e.: 

00: User provided not verified. 

01 : User provided verified, and passed. 

10: User provided verified, and failed. 

1 1 : Network provided. 

Numbers in the category "00: User provided, not verified" convey the meaning that the recipient shall treat the number 
as unreliable. If the called party does not want to receive calls from uncertain numbers he need not answer the call. 
Where the interface fom the Gateway is an NNI the and authentication allows it the number may be given as either 
verified and passed, for a limited range of presentation numbers. Since this range of uncertainty is already conveyed it is 
not necessary to generate a new category solely for internet use. There is no greater uncertainty about an internet 
telephony number than about one which is user provided, verified and failed. The issue of whether that extra information 
should be displayed on analogue display devices is a matter for national regulators. 
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D.4.2 Network number 



For a normal telephone call the Network number is usually the same as the calling party number. In some cases the 
caller will choose not to release that number to the called party, nevertheless the callers number is transmitted to the 
terminating exchange with an indicator that it is not to be released. Certain customer lines, such as emergency services, 
are provided with an override facility which allows the calling number to be released irrespective of the caller's 
preference. The protocol used and the means of display is a national matter. 

When a presentation number is provided either by the user or by a Gatekeeper the type of number is not set to network 
number unless the actual identity of the user is verified and can be treated with the same certainty as an equivalent fixed 
network calling number. The purpose of this subclause is to describe how to find a calling party number which can be 
used by law enforcement agencies in order to commence investigations in the same way as for a normal fixed network 
call. 

There are a number of different configurations which need to be considered but the main issue is that of trust. For the 
scheme to meet its objective there shall be trust between the parties involved in the call which is equivalent to that 
between network operators providing calling line identities in today's network. The configurations include: 

directly connected IP links to the Gateway provider; 

indirectly connected permanent IP links to the Gateway provider; 

dial-in links to the Gateway provider; 

dial-in links to an indirectly connected Gateway provider; 

connections where the other providers act only third parties conveying IP traffic as if via a private data switch. 



D.5 In-band information 



The SCN may provide in-band information before the CONNECT message is sent. In-band information can be sent in 
the form of tones or announcements. 

Some reasons for in-band information are as follows: 

information to the calling user that the SCN telephone is ringing; 

SCN wants to give information to the calling user about the progress of the call, e.g. "You have now dialled the 
police please disconnect or wait and the call will be set-up"; 

- progress tone is sent to avoid silence while routing over low speed routes; 

the called party number has changed and the new number is announced (changed number interception service); 
different types of interception services giving announcements; 
different types of interception services routing the call to an operator; 

- prompt the calling user for more information. This case applies for some IN services and it takes place before the 
active phase. 

To allow in-band information from the SCN to be transported to the terminal, the audio channel may be set-up before 
the SETUP message is sent to the SCN. 
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D.5.1 Call to operator/Non-chargeable calls 

If the user places a call to an operator who is connected to the SCN, or if the call is routed to an operator because of the 
invocation of a service, it might happen that the operator does not return a B-answer, i.e. there will be no CONNECT 
message sent from the SCN to the gateway. The reason for this behaviour is that the operator does not want to start 
charging. 

D.5.2 IN Services 

The user shall be able to utilize IN services within the SCN. Some of the IN services are simple number translation 
services while other IN services require user interaction. 

When user interaction is required the IN node prompts the user, using in-band information, and the user answers, using 
DTMF tones. 

The IN node may operate in two different modes: 

answered mode, i.e. the IN node sends a B-answer towards the calling user and then continues with the 
interactive part; 

non-answered mode, i.e. the IN node requests the SCN to establish the voice channels in both directions and then 
continues with the interactive mode. 

The answered mode will be experienced by the Gateway as a normal call while the non-answered mode will be 
experienced as a progress indicator No. 8 "In-band information or appropriate pattern is available" in a CALL PROC 
or a PROGRESS message. 



ETSl 



21 TS 101319 VI .6.4 (1 998-1 2) 



Bibliography 



The following material, though not specifically referenced in the body of the present document or not yet publicly 
available, gives supporting information. 

TR 101 300: "Telecommunications and Internet Protocol Harmonization Over Network (TIPHON); Description of 
technical issues". 

EN 300 356: "Integrated Services Digital Network (ISDN); SignalHng System No. 7; ISDN User Part (ISUP) version 3 
for the international interface". 

ITU-T Recommendation H.246 (1998): "Interworking of H-Series multimedia terminals with H-Series multimedia 
terminals and voice/voiceband terminals on GSTN and ISDN". 

ITU-T Recommendation Q.731 (1993): "Stage 3 description for number identification supplementary services using 
SignalUng System No. 7". 



ETSI 



22 



TS101 319 V1. 6.4 (1998-12) 



History 



Document history 


Vl.6.4 


December 1998 


Publication 



























ISBN 2-7437-2555-9 

Depot legal : Decembre 1998 



ETSI 



